06/26/2006 18:24 FAI 7036108686 



MILES & STOCKBRIDGE 



Application No. 09/973 ,769 Attorney Docket No, T3497-9052USO1 

REMARKS 

Applicant respectfully requests favorable reconsideration of this application as 
amended. 

Regarding the IDS submitted on 27 February 2006, Applicant notes thai the 
correct citation numbers for the three references identified on page 2, item 3 of the Office 
Action were listed on the Form 1449 submitted with the JDS filed 23 March 2006 as 
items 10-12 of Sheet 2. These items were indicated as having been considered by the 
Examiner on 24 April 2006- A copy of the seventh item of Sheet 5 of the 27 February 
2006 IDS is submitted herewith for consideration. 

Claims 1-20 and 22^8 are pending. Claim 21 has been canceled without 
prejudice or disclaimer. Claims 29 and 35-48 are allowed. Claim 25 has been amended 
herein. Claims 1-20, 22-28 and 30-34 presently stand rejected on the merits and will be 
discussed below. 

Applicant thanks the Examiner for allowing Claims 29 and 35-48, 

In the Office Action, Claims 1, 2, 4, 8 and 9 were rejected under 35 ILS.C. § 
103(a) over Shwed in combination with Scott. Claim 3 was rejected under 35 U.S.C § 
103(a) over Shwed in combination with Scott and Shipley. Claim 5 was rejected under 
35 U,S,C § 103(a) over Shwed in combination with Scott and Periasamy. Claims 6 and 
7 were rejected under 35 U,S,C. § 103(a) over Shwed in combination with Scott and 
Kent, RFC 2401. Claim 10 was rejected under 35 U.S.C. § 103(a) over Shwed in 
combination with Scott and Gleichauf. 

Further, Claims 11-13, 15, 17, 25-28, 30 and 32 were rejected under 35 U.S.C, § 
103(a) over Shipley in combination with Radia. Claim 14 was rejected under 35 U.S.C, § 
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103(a) over Shipley in combination with Radia and Feriasamy. Claim 16 was rejected 
under 35 U.S,C. § 103(a) over Shipley in combination with Radia and Kent, RFC 240L 
Claims 18 and 33 were rejected under 35 U.S.C § 103(a) over Shipley in combination 
with Radia and Scott. Claims 19 and 34 were rejected under 35 U.S.C. § 103(a) over 
Shipley in combination with Radia and Gleichauf . Claims 20 and 22-24 were rejected 
under 35 U.S.C. § 103(a) over Shipley in combination with Datta. Claim 31 was rejected 
under 35 U.S.C. § 103(a) over Shipley in combination with Radia and Shwed. 

The rejections of Claims 1-20 and 22-24 under 35 U.S.C. § 103(a) are respectfully 
traversed. Independent Claims 1,11 and 20 recite, inter alia, a communication module 
for isolating a node by selecting from among redundant communication paths in the 
digital network. As acknowledged in the Office Action with respect to allowed Claim 35, 
the prior art apparently fails to teach this feature. 

Scott discloses redundant communication paths to network nodes. See Scott, Fig. 
5; col. 4, line 29 to col. 5, line 58. Scott further discloses isolating nodes by assigning 
each node a particular "isolation state" from among six different isolation states of 
varying access permission. Scott, col. 5, lines 15-59. Scott does not disclose or suggest 
selecting from among redundant communication paths to isolate a node. 

The Office Action acknowledges that Shwed does not disclose or suggest this 
feature. Shipley, Feriasamy, Kent RFC 2401, Gleichauf, Radia, and Datta also 
apparently do not disclose or suggest this feature. 

Without acceding to the rejection of Claims 25-28 and 30-34 under 35 U.S.C, § 
103(a), Claim 25 now recites, inter alia, at least two locking devices, wherein each 
locking device is configured to interrupt communication to at least one other node of said 
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digital network. This feature, described at page 12> lines 1 1-14 of Applicant's disclosure, 
is apparently not disclosed or suggested by the prior art. Raclia discloses "locking" of 
"learned" IP addresses to prevent "the IP address from being releamed until a 
predetermined time has elapsed." See Radia, col. 3, lines 5-13. Thus, Radia does not 
disclose or suggest locking devices that interrupt communications. As acknowledged at 
page 8 of the Office Action, neither does Shipley. Therefore, Applicant respectfully 
submits that Claim 25 and its dependents patentably distinguish from the prior art. 

The clarificatory amendment to Claim 25 should not be considered a narrowing 
amendment. 

Therefore, Applicant respectfully requests this application be passed to issue- 
Should the Examiner believe that any further action is necessary to place this 
application in better form for allowance, the Examiner is invited to contact Applicant's 
representative at the telephone number listed below. 

The Commissioner is hereby authorized to charge to Deposit Account No. 50- 
1165 (T3497-9052USO1) any fees under 37 CRR. §§ 1.16 and L17 that may be required 
by this paper and to credit any overpayment to that Account. If any extension of time i$ 
required in connection with the filing of this paper and has not been separately requested, 
such extension is hereby requested. 



Miles & Stockbridge, P.C. 
1751 Pinnacle Drive 
Suite 500 

McLean, Virginia 22102-3833 
(703) 903-9000 
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XML: the new document standard - extensible Markup Language 
Emedia Professional, June, 1998 by Robert J. Boeri, Martin Hensel 

Everybody within a few degrees of hypertext circles knows that extensible Markup 
Language (XML) is hot But what is it, how does it compare with HTML and SGML, and 
how will it affect your electronic publishing efforts? 

Definitions first: XML is both the name of a specific standard and an umbrella term for 
three distinct, complementary standards: XML, The extensible Linking Language (XLL), 
and the extensible Style Language (XSL). And true to its SGML lineage, XML really 
isn't a language at all, but rather a standard for creating markup languages. 

XML will change everything from the way you code your Web pages to the way you 
manage digital document collections. Its first point of impact will be Web applications, 
but soon XML will encompass CD/Web hybrids and structured off- Web data as well. As 
the relentless move toward making Web browsers the universal interface to information, 
it will matter less where that information is found And as XML becomes integrated with 
Web browsers, XML's impact on data will grow far beyond the Web. 

Standard Generalized Markup Language (SGML), an International Standards 
Organization standard approved in 1986, defined the rules for creating textual markup 
languages. Although HTML has SGML roots (and in its pure form, HTML is truly an 
application of SGML with a Document Type Definition), HTML as practiced would fail 
any SGML stress test. Until recently, HTML was largely presentation-oriented (e.g., <B> 
for "bold' 1 ) instead of concerned with structure (e.g., <list_itein>) as is SGML. But like 
Henry Ford's Tin Lizzy, HTML gave birth to a vigorous new industry, was simple and 
affordable, and came without options. At the other extreme, SGML was designed to be 
quintessential^ general yet was neither simple nor affordable. The SGML specification 
alone is about 300 pages long. 

In 1997, the Web "market" was ripe for something in between these extremes; enter 
XML. Unlike its SGML parent, XML is not an ISO standard but instead was developed 
by a consortium of nearly 300 companies under the aegis of the World Wide Web 
consortium. And its specification is about a tenth the size of its parent's. XML was 
conceived by the scent of commercial profit, the enormous popularity of the Web, the 
limitations of HTML, and the realization that file systems from local hard drives to the 
Web needed integration and access via a Web browser. Accef >ted as a recommended 
standard in February 1998, XML now comes with an industry guarantee that it is stable 
and will deliver the interoperability that the Web demands. 

WEB-ENABLED AND STRUCTURED 

XML by itself can be used to model and deliver structured data without any reference to 
documents, and that may prove one of its earliest uses. However, to be useful as a 
document delivery standard, its two companions— the style and linking standards—must 
also be defined, XSL defines how to display each markup tag: color, size, font attribute, 
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and the like. Think of XSL as a downsized version of SGML's Document Style 
Semantics Specification Language, which attempted to define rules for displaying 
SGML-tagged data. 

XLL, whose SGML parent is HyTime, is designed to enhance the hypertext links that 
make the Web work. Instead of providing one-to-one paths between documents, XLL 
will take advantage of XML structure. Today, clicking on a link such as "Drug Family" 
could transfer you to a specific anchor point in an aspirin medical document; clicking on 
a link such as "Drug Interactions" might take you to a different anchor point in that same 
aspirin document In XLL, clicking on the link could let you jump to a pop-up list of 
sections in the aspirin document, such as drug interactions, drag family, warnings, or 
other sections. 

Beyond allowing publishers to create their own custom tag sets, XML has been designed 
specifically to allow real-time use. By trimming the generality of SGML, XML will 
allow browsers to interpret and display a stream of tags and data. Further, XML's 
structure will enable focused searching (e.g., find all "toxic" within "Warning" tags). 

True to its SGML roots, XML will require publishers to have a clear idea of what their 
documents' structures can be. Follow the rules of XML, and your parser can infer the 
structure of your documents from clues in the use of the tags. But publishers beware: 
unlike HTML, which you could abuse with nonstandard extensions or even misspelled 
tags (which browsers would graceftilly ignore), XML is strict. In fact, the XML standard 
says in effect that XML browsers must refuse to process an XML document that isn't at 
least implicitly structured, or "well-formed," 

LINKS TO SGML ROOTS: COMMON THREADS IN HYPERTEXT'S FUTURE 

Like XML, HTML 4.0 is a recommended specification. You don't have to look very hard 
to see how these two standards, although fundamentally different, reveal their common 
SGML ancestry, HTML 4.0 places tags into three categories of suggested use, each 
corresponding to an SGML Document Type Definition; Strict (including all tags and 
attributes that have not been deprecated— discouraged from use and possibly soon to be 
removed from the spec), Transitional (all strict plus all deprecated tags and attributes), 
and Frames (all Transitional plus tags supporting frames). 

Note that most deprecated tags have been demoted to that status because they dealt with 
visual presentation, and SGML and XML both separate form from content. Instead, 
HTML 4,0 encourages the use of style sheets to apply form to your content much like 
XML. 

As HTML evolves along a path that draws it even closer to its once-dissimilar cousin, 
XML's impact becomes as ubiquitous as the Web itself. 
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Robert J. Boeri (bboeri@world.std*com) and Martin Hensel (mhen5el@hensel.com) are 
columnists for Information Insider. Boeri is Information Systems Publishing Consultant 
at Factory Mutual Engineering of Norwood, Massachusetts. Hensel is president of 
Texterity Inc., a Newton, Massachusetts-based consulting firm that builds SGML-based 
editorial and production systems for publishers, corporations, interactive services, and 
compositors, 

Comments? Email us at letters@onlineinc.com, or check the masthead for other ways to 
contact us. 
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